IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within a communication session. It is also possible to combine media in a session, and the number of services offered to end users continues to grow, enriching the inter-personal communication experience. The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. The IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, the IMS introduces additional functionality for e.g. subscription handling, security and charging to allow operators and service providers to control user access to services and to charge users accordingly.
FIG. 1 illustrates schematically how the IMS 2 fits into the mobile network architecture in the case of a GPRS/PS access network. Call/Session Control Functions (CSCFs) 4 operate as SIP proxies within an IMS core network 2a. A user accesses the IMS 2 via an access network 5 and gateway nodes in a connectivity layer 6. The user must register with the IMS using the specified SIP REGISTER method in order to gain access to IMS services. A Home Subscriber Server HSS keeps a log of users' subscription profiles that define the services that the user has subscribed to. After registering, the user is able to establish a communication session with other peers, making use of the multimedia capabilities of the IMS. The IMS also includes a service network 2b, in which Application Servers (ASs) 8 are provided for implementing IMS service functionality. Application Servers 8 provide services to the end-users, and may be connected either as end-points over the 3GPP-defined Mr interface, or “linked in” (invoked) by an S-CSCF over the 3GPP-defined ISC interface.
SIP and IMS architectures are centred around a “call” model where services offered to end users are provided by either device applications or Application Servers in the network. FIG. 2 is a schematic illustration of a session path during the establishment phase of a SIP session in accordance with known current practice. This shows how a call/session between an originating peer (caller) 10 and terminating peer (recipient) 12 is currently established in the IMS. Each peer 10, 12 operates a SIP terminal, and is registered with an IMS network. Thus, as shown in FIG. 2, there is an IMS network on the originating side and an IMS network on the recipient side. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) 4a which is the first point of contact within the IMS for the caller 10 and recipient 12; the Serving CSCF (S-CSCF) 4b controls the provision of services to the users in accordance with the user's subscription; and the Interrogating CSCF (I-CSCF) 4c whose role is to identify the correct S-CSCF 4b, based on the user's subscription profile which it obtains from the user's HSS 6, and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF 4a. Services requested by the peers 10, 12 are identified at the session initiation stage and are provided by linking in the appropriate Ass 8a, 8b, in the IMS networks.
Currently SIP technology (as described in the Internet Engineering Task Force Request for Comments, IETF RFC 3261) provides for sessions to be established between communicating parties and for the media transfer between peers to be associated with a certain session or “call”. This call/session is handled by an application, typically implemented as a device application and sometimes with network support by an application server (AS 8). The device application provides the graphical user interface, GUI, implemented for the service (e.g. for a videotelephony call). The session is set up in an initial condition, making use of an initial media service, or set of media services provided by one or more ASs. Once the session is established, the initial media can either be replaced by another type of media, or additional media can be added between the parties. For example, initial audio can be replaced by video, or video can be added to initial audio creating a videotelephony service.
The device application responsible for the GUI and SIP session handling has no problem when changes are made to the services provided within the same session—i.e. when the change is initiated by one of the communicating peers. WO2006/125471 describes the inclusion of service identifiers as feature tags in SIP messages. The service identifiers identify a particular communication service to which a SIP message relates. This application also describes a MCS-qualifier that enables an application to correlate several simultaneous IMS sessions. An Internet Engineering Task Force (IETF) Sipping Working Group Internet Draft, dated Jun. 25, 2006 but now expired, describes a “Same-Session” SIP header field to logically correlate an existing SIP dialog with a new dialog.
However, it is not currently possible for a third party source to initiate the addition of media to an established SIP session such that the additional media is associated with the established SIP session. Also, not all IP media communications occur during established SIP sessions. There are many communications, or SIP transactions, in which a message is sent from one network source, such as a user terminal or an AS, to another user's SIP terminal but which does not entail establishing a session. Examples include notifications sent from the IMS to a registered user terminal by exchange of SIP MESSAGEs such as might occur as communications in a game being played between two peers. Again, there is currently no method to enable a third party source to add service media or functionality to these communications.
At present, for an AS to provide a service at any time during the lifetime of a session, it must be linked in during the establishment phase. It cannot be linked in later, due to inherent characteristics of the SIP protocol. In many cases this is not a problem (e.g. when providing telephony-like services to voice over IP calls). However, for other services it is a severe restriction or is wasteful of resources, especially for services that are only needed conditionally. In such cases, it is at present necessary to always link these services into the session path at session establishment, which leads to longer call set-up times and ties up unused resources.